1. Related Applications
This application is the U.S. national phase of International Application No. PCT/GB2006/001745 filed 12 May 2006, which designated the U.S. and claims priority to EP 0525963.3 filed 13 May 2005, the entire contents of which are hereby incorporated by reference.
This application is related to co-pending and commonly owned application Ser. No. 11/914,259 filed Nov. 13, 2007 now U.S. Pat. No. 7,933,200 issued Apr. 26, 2011).
2. Technical Field
The present invention relates to the field of communication systems in general and to the control of traffic in communications systems in particular.
3. Related Art
Network overloads can seriously degrade the quality or availability of telecommunications services if they are not effectively controlled. There is a need for effective, automatic controls to protect a range of service platforms from demand levels that are becoming increasingly volatile and unpredictable.
In telephone networks overloads can be caused by the following (either singly or in combination):                media-stimulated mass calling events—such as televotes, charity appeals, competitions and marketing campaigns,        emergencies,        network equipment failures,        auto-scheduled calling,        
In the absence of effective overload controls, such overloads would threaten the stability of network systems and cause a severe reduction in successful call completions. Ultimately, systems would fail due to lost tasks and services would not be available to customers.
A network operator could not economically provide sufficient capacity to manage the kind of calling rate peaks that can occur. Moreover in an overload, most service requests cannot be terminated successfully because the terminating lines are busy. Therefore overload controls are needed to manage peaks.
An example of this phenomenon is where TV set-top boxes simultaneously start (e.g. at 2 am) to dial-up a server on the internet in order to upload or download customer data. The problem is that there are typically only sufficient terminating lines to handle a small fraction of the calls offered per unit of time; and the instantaneous peak demand may exceed available signalling or processing capacity. One challenging feature of such auto-scheduled events is that the boxes can all follow exactly the same call-script, so that—after failure to establish a first call attempt—all the set-top boxes then follow exactly the same repeat sequence, with identical inter-repeat delays.
For any specific network context, the number of nodes causing a resource to be overloaded can vary widely from one event to another. The conclusion is that in many contexts an effective overload control must be able to cope automatically with variation in the way that traffic is distributed over the overload sources, which may change from one event to another or even during an event.
In a network, different instances of a particular type of resource may have (by design) widely different capacities. ISUP ACC could be used, for example, to protect end nodes (of relatively low capacity) as well as transit nodes (of larger capacity). Furthermore, an individual target resource's capacity in service requests/sec can vary over time. A good control should therefore be able to adjust to cope automatically with such variations in target capacity.
In most network systems call processing is divided among several different sets of processing resources. For example, in telephone switches, it is often divided between peripheral processors which handle sets of traffic routes and a pool of load-balanced central processors which handles call routing, charging, etc. Consequently, it is possible that different sets of processing resources could become the bottleneck as call mixes and the patterns of call flow through the system vary. The system's internal load control therefore needs to reject calls in order to keep response times low and to guarantee correct call handling whatever internal processing resource is overloaded.
For a specific mix of offered demand, the typical throughput curve for a network system is shown in FIG. 1. The resource could be a telephone switch, a Service Control Point (SCP), a Signalling Transfer Point (STP), an ATM node, a World Wide Web server etc.
The exact shape of the admission rate curve will depend on which internal processing resources are the bottleneck for the offered demand mix. However, generally, as the offered request rate increases, there will come a point where the resource invokes its internal overload control to reject some part of the offered load in order to limit the admitted load and consequent delay at the bottlenecked processing resource. At this point therefore the admitted rate will begin to fall below the offered rate and eventually reach a maximum admitted rate (since rejecting service requests consumes processing effort) at some definite offered rate (denoted by LM in FIG. 1).
Further increasing the offered rate causes the admitted rate to actually fall. Eventually there comes a rate (denoted by LC service requests/second) where correct call handling cannot be guaranteed and all calls are rejected. This can occur, for example, in telephony switches if internal task queues overflow and the switch may have to restart or roll back to restore itself to a ‘sane’ state. To restore the resource to normal working, the offered rate will need to be reduced to a level at which the resource is no longer in overload.
In addition—as is illustrated in FIG. 1—the response time of the target resource to a request will start to increase as internal congestion builds up. This response time can be kept to an acceptably low (and roughly constant) level for a certain range of offered rates by means of the target's admission control reducing the rate at which calls are accepted for full processing. Eventually, however, the processing effort of rejecting or discarding calls can itself exhaust the processing capacity available to reject calls (this occurs when the offered load is LC). At that point response times can start to climb rapidly and uncontrollably, triggering high rates of customer abandons and reattempts.
It is important to maximise the target's admitted rate—subject to keeping response times small enough—in order to minimise customer reattempts. This also avoids the sources over-throttling the request streams destined for the target, which would generate unnecessary customer repeat attempts.
For any specific network context, the number of nodes causing a resource to be overloaded can vary widely from one event to another. Furthermore, an individual target resource's capacity in service requests/second can vary over time.
The original idea of ‘Intelligent Networks’ was to be able to define a system capability that would support the rapid building and deployment of a large range of new services into a telephony network. Services include those with advanced call distribution features, such as call queuing. The ITU-T specifies a series of recommendations that define such a capability, incorporating the INAP (Intelligent Network Application Protocol, [3]). A BT Technical Journal special edition on network intelligence provides an overview of Intelligent Networks, standards and services [1].
Although overloads can occur simply because insufficient capacity has been provided for the demand expected, it is more common for overloads to be caused by some quickly arising event, which may be unanticipated. These include network or system failures, tariff changes and network system processes that have been scheduled to occur synchronously. They also include the type of services deployed on an IN, such as media stimulated events or natural emergencies (e.g. bad weather) and so the traffic can be very volatile. To make matters worse, traffic is usually magnified by calling customer or system repeat attempt behaviour. Any system needs effective overload controls in order to avoid excessive response times and reduced throughput or even failure. In the case of an IN, there are architectural reasons why it may be especially susceptible to overload, which are explained below.
The essential components of the ITU-T IN functional model are shown in FIG. 2. The SCF (Service Control Function) 10 contains call control functions composed of the fundamental building blocks of services. These interact with service logic and data and interface to other functions including the SSF 12 and SRF 14. The SSF (Service Switching Function) 12 extends and modifies call control functions to allow recognition of IN service control ‘triggers’ in order to query the SCF 10 and manages signalling between the call control and SCF 10. The signalling message resulting from a triggered ‘Detection Point’ is an ID/P (Initial Detection Point), sent from the SSF 12 to the SCF 10. The SRF (Specialised Resource Function) 14 provides the resources required for the execution of IN provided services, e.g. digit receivers and announcements. The node which hosts the SCF 10 is usually referred to as an SCP (Service Control Point) and that which hosts the SSF 12, i.e. a switching system, as an SSP (Service Switching Point).
While the ITU standards specify an Intelligent Network in a distributed manner, independent of physical realisation, a typical IN architecture is centralised in the following sense: there are normally only a small number of SCF 10 instances and many instances (possibly hundreds) of SSFs 12 per SCF 10. Such high connectivity in combination with the usual capacity of each SSP means that the total demand that can be generated by the SSPs can easily be much greater than an SCP's capacity. Furthermore, the total SCP capacity is usually much greater than that of (say) a destination switching system to which it instructs connections to be made. Thus if an overload is focused in nature, i.e. the traffic is concentrated onto one or a few destination systems, then there are two possible consequences:                a destination or the intermediate network, may not have an adequate overload control to limit the load processed, resulting in degraded performance (excessive response time or reduced throughput);        even if controls are adequate, the bulk of the calls processed by the SCFs 10 may be ineffective because the destination resources (lines) are busy. The SCFs 10 would then be processing a large amount of ineffective workload, which may be causing other calls to be rejected that would otherwise have had a good chance of completing. The effective throughput of the SCFs 10 would, therefore, decrease.        